第 3 小节：开源许可证的应用

选择一个合适的开源许可证

相信对于很多刚踏入软件这个行业的小伙伴来说，「开源软件许可证」是个比较陌生的概念，毕竟在现阶段如何写好手中的代码才是更加重要的事。但是随着经手项目逐渐增多，会发现很多项目，尤其是一些大型项目，经常会引用到别人一些优秀的开源代码，而这些优秀的开源代码通常都会在最开始简单地附上一段关于授权的声明或在项目根目录下提供完整的授权声明文件，比如：「The project is licensed under the Apache 2 license.」，诸如此类便是「开源许可证」。

声明开源许可证，可以让广大开发者看到并获取我们作品的同时又保留了我们作为作者的一些权利。在提高自身业界知名度的同时又能防止有人将作者名字改成自己，拿去谋取利益。

开源不等于免费，开源也不等于没有约束。

开源许可证概述

开源许可证是开源软件的授权许可，里面详尽表述了个人或组织获得开源代码后拥有的权力，包括可以进行哪些操作以及禁止哪些操作。对于绝大部分人来说，与其自己花大把时间去编写一份开源许可证，倒不如直接选择一个广为流传且合适的已有开源许可证，这样做既省心又省力。而且，靠个人完成一份开源许可证的编写也不是一件容易的事情。

常见开源许可证授权概述

协议 描述 要求 允许 禁止
LGPL 主要用于一些代码库。衍生代码可以以此协议发布（言下之意你可以用其他协议），但与此协议相关的代码必需遵循此协议。 1.公开源码 2.库引用 3.协议和版权信息 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 1.责任承担（禁止让作者承担责任，可以理解为免责）
Mozilla Mozilla Public License (MPL 2.0) 是由 Mozilla 基金创建维护的。此协议旨在较为宽松的 BSD 协议和更加互惠的 GPL 协议中寻找一个折衷点。 1.公开源码 2.协议和版权信息 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 1.责任承担 2.商标使用
GPL 此协议是应用最为广泛的开源协议，拥有较强的版权自由（copyleft）要求。衍生代码的分发需开源并且也要遵守此协议。此协议有许多变种，不同变种的要求略有不同。 1.公开源码 2.协议和版权信息 3.声明变更 1.商用 2.分发 3.修改 4.专利授权 5.私用 1.责任承担 2.附加协议
BSD 较为宽松的协议，包含两个变种 BSD 2-Clause 和 BSD 3-Clause，两者都与 MIT 协议只存在细微差异。 1.协议和版权信息 1.商用 2.分发 3.修改 4.私用 5.附加协议 1.责任承担
MIT 宽松简单且精要的一个协议。在适当标明来源及免责的情况下，它允许你对代码进行任何形式的使用。 1.协议和版权信息 1.商用 2.分发 3.修改 4.私用 5.附加协议 1.责任承担
Apache 一个较宽松且简明地指出了专利授权的协议。 1.协议和版权信息 2.声明变更 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 1.责任承担 2.商标使用
AGPL 一个严格的开源协议，除非获得商业授权，否则无论以何种方式修改或者使用代码，都需要开源。 1.公开源码 2.协议和版权信息 3.声明变更 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 1.责任承担

木兰协议介绍

协议 描述 要求 允许 禁止
MulanPSL 一个简洁明了宽松的开源协议，对开源的各种实体做出了明确的定义，以中英文双语表述，中英文版本具有同等法律效力。如果中英文版本存在任何冲突不一致，以中文版为准。 1.协议和版权信息 1.商用 2.分发 3.修改 4.专利授权 5.私用 6.附加协议 1.责任承担 2.商标使用
  • 许可证明确不提供对“贡献者”的商品名称、商标、服务标志等的商标许可，保护“贡献者”的切身利益。
  • 解决联盟存在互诉漏洞，也就是 A 想诉 B，A 授权 C，由 C 可以诉 B 的问题。
  • 比 Apache License 更友好一些，Apache License 要求列出每个修改文件，其实很多项目做不到这一点，所以 MulanPSL 直接取消了这项要求。

快速选择

国内大神阮一峰根据乌克兰程序员 Paul Bagwell 的开源许可证选择分析图翻译的一份 中文版本，是我目前见过的最通俗易懂的解析，因为语法支持的问题，用以下代码大致表示为：

  1.                                                              他人修改源码后，
  2.                                                               是否可以闭源？
  3.                                       ---------- No ----------             ---------- Yes ----------
  4.                                       │                                                            | 
  5.                                       │                                                            |
  6.                                       |                                                            |
  7.                                       |                                                            |  
  8.                                 新增代码是否采用                                            每一个修改过的文件，
  9.                                   同样许可证？                                              是否都必须放置版权
  10.                     ----- No -----           ----- Yes -----                                       说明？ 
  11.                     |                                      |                         ----- No -----     ----- Yes -----
  12.                     |                                      |                         |                                |
  13.                     |                                      |                         |                                |  
  14.                     |                                      |                         |                                |
  15.              是否需要对源码的                               |                         |                                |
  16.              修改之处，提供说                               |                   衍生软件的广告，                        |  
  17.                  明文档？                                  GPL                 是否可以用你的名                      Apache
  18.     ----- No -----       ----- Yes -----                                           字促销？                            
  19.     |                                  |                             ----- No -----       ----- Yes -----
  20.     |                                  |                             |                                  |
  21.     |                                  |                             |                                  |
  22.     |                                  |                             |                                  |
  23.     LGPL                             Mozilla                         BSD                                MIT

使用 Gitee 开源许可证向导来选择

为了解决大家对于开源许可证的选择困难症，Gitee 还制作了许可证选择向导。

当你在 Gitee 创建一个公开的仓库（如果为私有仓库，则不提示建议创建许可证），而且该仓库没有创建许可证文件时，Gitee 会在代码界面中智能地提供开源许可证创建向导来对你进行引导。如图所示：

出现创建许可证提示

如果你需要通过向导来创建，请点击点此选择并创建开源许可链接。

弹出的许可证向导介绍页面

在弹出的界面中，如果你需要创建自定义的许可证，请点击左下角的创建自定义许可证按钮，会自动创建一个 LICENSE 文件，你可以填入自定义的许可证内容，并进行代码提交即可。

如果你需要使用向导，请点击右下角的开始选择。

许可证向导页面

接下来，你可以看到一个向导页面，向导页面的原理为通过一系列问题的形式了解你怎样的内置许可证更适合你的项目。如上图所示，我们需要回答设定好的七个问题，每个问题会有详细的解释，请通过你对于你项目的判断如实进行答案选择，然后点击下一步继续下一个问题的回答。

在回答的过程中，你可以随时在下面列举出的内置许可证中选择你需要的许可证，点击右下角的使用该许可证结束向导。也可以在回答完所有问题之后，根据评分来进行选择。

回答完许可证向导问题后

如上图所示，我们已经根据需要回答完了所有的问题，Gitee 会自动对所有许可协议进行评分，一般你可以在得分最高的内置许可证中选择自己需要的即可，按下右下角的使用该许可证即可添加该 LISENCE 文件到项目的根目录下，十分方便。

在确认之前，每个许可证都对每个问题有详细的回答，许可证被扣分的原因是某许可证并不是所有的方面都符合你的要求，你可以仔细阅读你关心的部分后再慎重做出选择。

当然，该向导功能未来还将继续完善，增加问题引导或增加可选择的内置许可证等。目前该向导也存在部分对用户不友好的体验内容，比如没有突出展现每个许可证的评分扣分点在哪里，是哪个条款；又比如内置许可证的名称一般只显示简称，对于对许可证的简称不够了解的开发者们进行选择不够友好等。这些内容 Gitee 官方都将在后续的优化中持续的优化，欢迎大家提出意见和建议。

关于修改开源许可证

开源软件的著作权属于作者所有，作者可以自行决定是否变更开源许可证，但是需要注意以下几点：

  • 变更授权之前的授权不能撤销
  • 如果有许多著作权所有者，需要共同同意
  • 如果使用多个开源许可证，变更开源许可证后，要防止不同开源许可证在授权上出现冲突的问题

参考资料

本部分内容贡献者

prog1mmer、雪山凌狐、zeroTwozeroTwo